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Abstract: This paper describes RaPiD, an assistant for the design of dental prostheses called 
removable partial dentures. The user nmnipulates icons directly to indicate the desired design solution 
lo a given clinical situation. A developing design is represented as a logic database of components in 
a design; expert rules are applied as integrity constraints governing valid database transactions/design 
vo alterations. Contravention of design rules is presented to the user in a critiquing style. T! e critiquing 

^ strategies form the basis for the system's use in undergraduate and graduate dental educaticwi. 

00 
00 

^ Tlie education of dental undergraduates includes instruction in the principles of the design of dental prostheses. 

Q Tlie design process is a complex and difficult task, and the time available in the dental curriculum to impart the 

required knowledge is limited. If students were to have open access to a knowledge-based system for the design of 
prostheses, there could be important educational benefits. Such a system, RaPiD (/Removable Partial Denture 
design using artificial intelligence), is now being developed by specialists in prosthetic dentistry and 
knowledge-based systems. RaPiD is usable both as a prescription system for dental practitioners and as a 
teaching system which can be configured for undergraduate and postgraduate use. RaPiD as a prescription system 
has already been described in the dental and AI literature (Hammond et al, 1993a and 1993b); this paper 
concenu-aies on its educational use, in particular on its critiquing strategies which guide a user through a design. 

1. Removable partial dentures 

A removable partial denture (RPD) is a denture provided for a patient who has some natural teeth remaining. 
It enables its wearer to chew food effectively, assists speech and helps to stabilise the remaining natural tectli; it 
may also enhance the patient's appearance. An RPD comprises up to 40 components, the most important of 
which are as follows. The saddles carry the artificial teeth and fit over the area of the gum from which natural 
teeth are missing. Rests are metal extensions which transmit biting forces from saddles to the adjacent natural 
teeth. Clasps are flexible metal clips which grip natural teeth, making a denture secure during function. Finally, 
a major connector is a rigid metal bar or plate which unites the other components into a single prosthesis. 

2. The motivation for the development of RaPiD 

Designing a satisfactory RPD requires clinical training and experience. The dentist should carry out a detailed 
assessment of the patient and of models of the patient's teeth and then draw a design to be sent to a dental 
technician as a prescription for the manufacture of the denture. However, general dental practitioners commonly 
delegate responsibility for design to technicians, whose training is inadequate to assess the clinical factors in a 
case. Tlie resulting denture may fit pooriy, and may even pose a threat to the patient's remaining natural teetli. 
Tlie rejisons for this delegation of responsibility are not entirely clear, although limited design experience may be 
crucial (Basker et al, 1978 and 1991). One factor which motivated the development of RaPiD was the desire to 
build an educational tool that could enhance tlie training of dental students and practitioners. A general dental 
practitioner in the UK designs, on average, one RPD a month, while in dental schools students may have to 
produce only five or six Rl^D designs for patients throughout Uieir undergraduate study (Holt et id, 1993). It is 
doubtful whetlier this frequency is sufficient to ensure adequate familiarity with good design principles, whether 
« by students or by graduate dentists. Clearly a knowledge-based system which uses a graphical interface allowing 

'{2 creation of new designs and alteration of existing ones, which incorporates all tlie principles governing 

^ correct design of RPDs and can detect and criUquc attempts to violate them, could be a powerful educational tix)l. 

^ ' Tlie evidence is, then, tJiat a system such as RaPiD will meet a genuine and pressing need. 

r~ 

— -PERMISSI ON TO RtPRODUCE THIS 

O MATERIAL HAS BEEN GRANTED BY 



ERJC TO THE fOUCATlONAL RESOUnCES 



217 Gary H. Markf 

2 



BESTCMAVWyiLE. 



INFORMATION CENTER (ERIC) ' 



3. Levels of operation of the system 



RaPiD has two modes of operation, manual and automatic. The manual mode is designed for educational use 
while the automatic version is intended for dentists in practice. The manual version can be run at two levels of 
difficulty, "student'* and "expert". In "student" mode a user who infringes a design rule is informed of the 
infringement immediately so that the system controls the user's progression through the design sequence towards 
an optimal solution. In "expert" mode the designer has a free hand: the design is developed by the user without 
any interference from the system and without any design infringements' being signalled. However, on completion 
of the design the result is appraised by RaPiD, rules that have been broken are listed and alternative soluUons 
displayed. In automatic mode the dentist enters key clinical information, after which the system takes over and 
completes the design. In all modes, editing of the final design is possible, and a graphical and textual summary 
of the result can be printed, as a record for the student/ for evaluation, or as an instruction to a technician. 

4. Designing with RaPiD 

Software development has taken place on Macintosh computers, using an implementation of Prolog, 
MacProlog (Logic Programming Associates, Ltd, London), which provides powerful object-orientated graphics. 
A prominent feature of RaPiD is its graphical interface which utilises the window-based environment standard in 
Macintosh applications. Figure 1(a) depicts a design window at the beginning of a design session, with a palette 
of tools at the left and the design area, containing a dental arch, in the remainder of the window. 




(a) Initial screen showing palette of tools (left) (b) A completed design for an upper arch, 

and design window with upper arch of teeth. 

Figure 1 

A user begins a design by selecting the "forceps*' tool (^^f^) and then clicking once on teeth icons to be 
made artificial, whereupon they become shaded. A double-click removes a tooth icon entirely when a tootli is to 

be missing and not replaced by an artificial tooUi. Tlie saddle-placement tool (^^) creates a saddle around tlie 

artificial teeth; another tool (@) places rests on teeth for support of saddles. There are tools also for placing 
different types of clasps on retaining teeth. The major connector which joins all the components of a denture has 
to be drawn by the user, employing a mouse. Other tools include one for giving information about individual 
components, and an editing tool for changing the shape of components. A design can be printed, together with a 
written summary, for sending to a dental technician for manufacture. Figure 1(b) shows a completed design. 

5, The use of critiquing 

The student of RPD design needs to be made aware of any design errors immediately and to be challenged to 
modify the design correctly. RaPiD achieves this through a range of critiquing strategies which alert tlie user to 
an error, efficiently but as unobtrusively as possible. Three examples will illustrate the use of critiquing, 
(i) Placing rests on supporting teeth. A saddle which is bounded at both ends by healthy natural teeth is 
supported by rests placed on the neighbouring teeth. However, with a free-end saddle, one bounded at only one 
end by natural teeth, this is impossible. Should the one supporting rest be placed on the neighbouring tooth 
mesially (at the end closer to the front of the mouth) or distally (towards the back)? Prosthetic specialists favour 
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mesial placement. An attempt to place a rest distally tlierefore fails and a critiquing message is presented, 
specifying what is wrong with the proposed alteration and advising correction (Fig. 2(a)). As with other rules, if 
exceptional clinical circumstances make the rule inappropriate, it can be overridden by means of a function key. 
(ii) Placing a gingivally-approaching clasps. A gingivally-approaching clasp is a type of clasp which reaches 
the undercut region of a tooth by passing from the saddle via the gingiva or gum. It is placed by drawing a line 
connecting the undercut on the gum area of a tooth with a point on the saddle to be clasped. (In Figure 1(b) there 
is a gingivally-approaching clasp connecting the saddle which carries three artificial teeth with its neighbouring 
natural tooth.) Hie clasp which retains a saddle should be placed on the tooth adjoining the saddle. So if a user 
attempts to draw a clasp starting from any tooth which does not neighbour a saddle, the alteration immediately 
fails. An error message directs the user to place the clasp on a neighbouring tooth (Figure 2(b)). 




(a) Incorrect placement of a rest: the user has (b) Incorrect placement of a gingivally-approaching 

attempted to place a rest distally; it should be clasp: the user has attempted to draw the path of 

placed mesially. (Mesial and distal locations not the clasp starting from a tooth (marked with "X") 

marked in actual design.) which does not neighbour a saddle. 

Figure. 2 Critiquing messages 



(iii) Drawing a major connector. A major connector should be added to a design only if all saddles are adequately 
supported by rests. In RjtPiD, once the user has selected the connector-drawing tool and clicked on a point within 
a dental arch to commence drawing a connector, a check is made of all the saddles in the arch. If any saddle is 
inadequately supported, the user is Immediately informed, and is required to remedy the deficient support. 

Example (i) above follows a somewhat different pattern from (ii) and (iii). In (i), the user indicates a chosen 
point for placing a rest, and the design check comes into operation. In examples (ii) and (iii), on the other hand, 
the user*s action is more complex and amounts to the completion of a process: in (ii) this is the drawing of a 
line linking the end-points of a gingivally-approaching clasp, in (iii) the drawing of the outline of a connector. 
In both (ii) and (iii) a user, having selected a tool, may immediately misuse it in such a way that it would be 
pointless to continue. RaPiD*s intervention does not, then, have to wait for the user to complete the alteration: 
rather, the operation faih and a critique is issued straight away. 

The two types of critiquing strategy considered so far are, then: 
(\)A critique is issued oniy w'hen the user has completed the proposed alteration; and 

(2) A critique is issued immediately upon the user's radical misuse of a tool 
Three additional modes of critiquing can be usefully employed: 

(3) Critiquing dynamically without negotiation with the user. This amounts to ccnrecting the user's action 
automaticaHy and dynamically. The user is not given any choice in the matter, nor informed that the attempted 
modification is being continuously conrected — although Uiis fact will be obvious from what happens (or fails 
to happen) in the graphic window. An example concerns the representation in RaPiD of a tooth's drifting along 
a dental arch following extraction of a neighbouring tooth. There is a tooth-drifting tool which can be employed 
to drag the icon of a tooth to a new location. But ilie tooth is movable only along the line of the aich of teeth. 

(4) Critiquing requested by the user upon completion of a design session, or at certain other stages in the design 
process. Certain design rules, concerned witli the overall balance of a design, are applicable only at llie end of a 
design session, or at any rate when the user lias finished placing all the major components of a denture. Tlicre 
arc, for instance, rules detennining whetlicr a design ensures tlie retention of a denture during function. These 
rules involve some complicated geometrical reasoning, centred on the relation of the denture*s axis of rotiition to 
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the retaining elements. RaPiD will apply these rules only when the user has developed the design sufficiently. 
(5) Optional critiquing, requested by the user who wishes to compare his design with that which would have 
been produced independently by the system, A user may complete a design without contravening any design 
rule, but it is unlikely that the design will be identical to that which the system would produce if operating in 
automatic mode. The user may, therefore, wish to compare his own design with one produced automatically. The 
sort of optional aitiquing suggested here amounts to listing differences between the two designs. The user's 
design can then be brought into line with that of RaPiD, if desired. (The fourth and fifth critiquing strategies 
have yet to be incorporated in the system; their addition will follow development of the automatic mode.) 

Some examples of the different types of critiquing strategy are set out in Table 1 below. Note that the nature 
of a critique varies according to the type of error committed. Sometimes the fact that a mistake has been made 
will be so clear to the user that a simple beep will suffice. At other times a detailed message is necessary. When 
the third critiquing strategy (automatic, dynamic correction) is being followed, this will be obvious simply from 
the fact that what the user is trying to bring about fails to tally with what actually happens. 



Alteration to design 
Placing rMt on tooth 



Moving tooth to 
new position 
Drawing a major connector 



Teating quality 

of daaign ao far 
Positioning a daap 



Constraint to be applied 



Critiquing strategy Nature cf critique 



1 . Rest is in corrBCt masial/distal position 1 

2. Tooth must not already carry 1 
a iBst in the same position. 

3. Tooth may be moved onfy 3 
to a point on the aich. 

4. All saddles in arch are property supported. 2 

5. Connector does not cover lorttdden" 1 
areas (tongue In lower arch, soft palate in upper). 

6. AJI design rules appropriate for 4 and'or 5 
stage reached are adhered to. 

7. Tooth is natural. 1 



Detailed nriessage. 
Beep. 

No message; correction is 
automatic and continuous. 
Detailed nrtessage. 
Detailed message. 

Detailed message (or 
sequence of messages). 
Beep. 



Table 1 Some examples of the different kinds of critiquing strategies. 



6. .The design representation employed in RaPiD 

Follov/ing a recognised convention, a tooth is identified in terms of the quadrant to which it belongs 
(quadrants 1 and 2 constituting the upper arch of teeth and quadrants 3 and 4 constituting the lower), and its 
number (in the range 1-8) within its quadrant. A given tooth may have the status natural or artificial or 
missing. In RaPiD, the components of a design are represented as a logic database, and the statuses of teeth, in 
particular, are represented by facts of the general form "toothJn_db(tooth(Quadrant,Number),Tooth,Status)'' — 
where the variable Tooth is instantiated by the name of the graphical object representing a tooth. For example: 
tooth Jn_db(tooth(1,8),tooth_18,missing)). 
toothJn_db(tooth(1 ,7),tooth J 7,artif icial)). 
Tlie existence of components is represented in the database by facts such as "rest_in_db(restl)'\ 
"saddlejn_db(saddle l,[tooth(l,5),tooth( 1,6)])", '^connector Jn_db(upper,connectoi2,multibar,metal)*\ Tliese facts 
state, respectively, that restl is a rest^ that saddlel is a saddle carrying artificial teeth 5 and 6 in quadrant I, and 
that connectoi2 is a metal multi-bar connector in the upper arch. There are also facts recording the relationships 
of components to one another: for example, "clasp_retains„saddle(claspl,saddle3)". 

A user's manipulation of the iconic representation of a design is interpreted as an alteration or update of the 
design database. If, for example, the incisor tooth (1,1) is to be represented as artificial, tlie fact 
"tooth_in_db(tooth(l,l),tooth_l Unatural)" is removed from the database and is replaced by tJie fact 
'*toothJn_db(tooth(l,l),tooth_ll,artificial)". Other design alterations present a more complex picture. If, for 
instance, a user attempts to place a rest on a tooth, the system surveys the state of the database and determines 
whether a rest in that position would have the function of supporting a saddle, or some other function such as 
ensuring the overall stability of the denture. In either case a fact of the form "rest_on_toothJn_db(Rest,Toothy' 
will be added to the database, whereas in the first case only, an additional fact of the form 
'*rest_supports_saddleJn_db(Rest,Tooth,Saddle)" will also be added. 

A RaPiD design is in the form of a deductive database and can be thought of as a set of clauses comprising 
both the facts relating to a given case and the design rules applicable to any case. Facts about the individual case 
are always atoms, while rules are expressed as extended Horn clauses (Kowalski, 1979), of tlie form 
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W 

where A is an atom and W is any expression (atomic, negative or conjunctive) of first-order logic. We could, for 
example, express as follows the rule that a rest supporting a free-end saddle should be placed on a tooth mesially: 
rest_onJooth(Rest,Tooth,mesial) 

saddle_in_db(Saddle,ArtificiaLteeth_on_saddle), 

tooth_associated_with_saddle(Tooth,ArtfficiaLteeth_on_saddle), 

type_oLsaddl6(Saddle,ArtificiaLteeth_on_saddle,free_end). 
This dsduclive-database approach provides (1) a clear, unambiguous description of the components in a design and 
of their relationship to one another, (2) improved modularity for grouping design rules, and (3) a logically sound 
procedure for checking database updates. (For general theoretical accounts of the nature of a deductive database, see 
Sergot, 1991 and Das, 1992.) To test whether a design modification is acceptable, we check the proposed change 
against the design rules, expressed as integrity constraints, conditions which the database is required to satisfy. 
Many of the integrity constraints used in RaPiD are dynamic, that is, constraints governing the transition from 
one state of the database to another during an attempted update. As such they are applied as preconditions for 
allowing a proposed modification to succeed. If an attempted modification satisfies all its preconditions, it is 
accepted and the database is updated. If the input fails to satisfy even one of its preconditions it is rejected and the 
database remains as it was. For instance, it is a precondition for placing a rest on a tooth that the tooth is a 
natural one; it is a precondition of placing a saddle on an edentulous area that that area is not already covered by a 
saddle. Given a full range o( precondition clauses, encompassing all the vaiious types of input, we rely on a 
procedure assimilate in the style of Kowalski and Sergot (Kowalski, 1979; Sergot, 1991) to handle the 
incorporation of attempted alterations. If tlie preconditions for an alteration are satisfied, an update procedure is 
used to incorporate the alteration in the database; if one of the preconditions is not satisfied, the alteration will 
not succeed and the nature of tlie failed precondition will determine whether a message should be presented to the 
user, or whether there should be some other response such as a beep. 

7. Evaluation of the system 

RaPiD^s user-interface and its graphical capabilities have been extensively tested by the project team and also 
evaluated by a consultant dental prosthetist, a panel of dental practitioners and a number of dental technicians. 
Their comments have been recorded and relevant improvements incorporated into the software. This process of 
evaluation by users of RaPiD as a graphical tool is continuing and will recruit teachers and students in other UK 
dental schools and postgraduate centres. In addition, an assessment of the graphical quality of the designs 
produced by RaPiD has been completed. A series of designs produced manually by students under staff 
supervision was obtained. Each design was reproduced using RaPiD, and both versions were returned together 
with a questionnaire to the originating dental staff for comparative assessment. The results for the RaPiD 
versions of the design were highly favourable (Hammond et al, 1993b). 

The design rules which are being incorporated into RaPiD are based, not on local preference, but on an 
extensive survey (now complete) of the literature. A detailed questionnaire has also been circulated to prosthetic 
specialists at all UK dental schools, aimed at gauging levels of acceptance of various design rules. The responses 
to this questionnaire of 10 specialists at the School of Dentistry in Birmingham have been recorded and analysed. 
The questionnaire is to be distributed to co-operating schools abroad. 

An assessment of the educational effectiveness of RaPiD is planned, and will be undertaken in two stages: 

(a) A project, undertaken in co-operation with the Faculty of Education, University of Birmingham, to measure 
any improvement in students* grasp of the design rules, and their ability to design a denture in accordance with 
the rules, resulting from tlie use of RaPiD. The project involves working with two groups of students in the 
Dental School who have completed their basic course in RPD design. One group will use a version ("expert" 
mode) of RaPiD in which die design rules are not applied to restrict users* actions in any way, although their 
achievement will be recorded Uirough an error log of design rules contravened during the design process and by a 
design quality index of the finished design: tlie latter index is a measure of the compliance of the finished design 
with the established design rules. The oUier group will use RaPiD in "student" mode with design rules operative 
so that students are guided to an optimal solution; again an error log and quality design index will be obtained. 

(b) 100 consecutive hand-drawn RPD designs for patients, produced by students witliout RaPiD* s assistance, 
liave been collected. The compliance of Uiese designs with the design rules is to be measured to produce a design 
quality index. The full "student" version of tlie system, once it has been completed, will be used to produce all 
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designs by students. A post-RaPiD design quality index will then be obtained and compared with the pne-RaPiD 
index to indicate the level of improvement within the school as a whole achieved by inuoducing the system. 

8. Related work 

Systems for RPD design have been described by Maeda et al. (1985 and 1987) Wicks and Pennell (1990) and 
Beaumont (Beaumont & Bianco, 1989; Beaumont, 1989). For some critical remarks atx)ut these systems, see 
Hammond et al, 1993b. The Kontest system (Jakslat et al, 1991) is concerned with undergraduate education; its 
effecuveness is, however, restricted because much data must at present be input at the kijyboard. It has not been 
possible to appraise the Stelligraphe system (J. Gaillard, Appolline Productions, Sainte-Usage, Louhans, 
Fiance), now in commercial use, because public-domain descriptions of the software are not yet available. 

9. Future work; concluding remarks 

Expanding the range of design rules in RaPiD so that it becomes comprehensive is a current priority, as is 
the introduction of criUquing strategies (4) and (5) (see section 5 above), as well as completion of the automatic 
mode of operation. The programme of evaluation of all aspects of RaPiD is now being actively pursued. The 
extensive use and testing of RaPiD already carried out show it to be a versatile and r(»bust knowledge-based 
system whose benefits in dental education will be widespread. 

Acknowledgement FJF and DAR are funded under the KBS Initiative of the UK Higher Education Funding Councils. 
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